@consideRatio To elaborate a bit, jupyter-server-proxy starts applications which then usually listen on localhost ports. jupyter protects the path to {jupyter_url}/application/ or {jupyter_url}/port/{port} so if anyone tries to access those URLs, they will not be able to auth. However the proxied application itself may not provide any additional authentication if a user connects to localhost:{port}. In a containerized environment this doesn't matter very much because only jupyter is exposed by the container. On a multiuser system however, if someone starts an application (through jupyter or otherwise) that is listening on localhost:{port}, another user on that system can connect to that same port without intervention. For example if user1 launches cd ~/secrets/; python -m http.server 9000, user2 can curl localhost:9000 and read user1's secrets.

Users may launch jupyter on multiuser systems from the command-line, or through JupyterHub when it uses spawners like batchspawner or systemdspawner.

Potential fixes for this:

• Support proxying to a server process via a Unix socket #337, which exposes the proxied app through a UNIX socket instead of an open port
• https://github.com/ryanlovett/portwrap, which runs the proxied app in a user/network namespace so that jupyter can connect to the open port and proxy it, but nothing outside of the namespaces can reach that port

Ah its a lot clearer to me now @ryanlovett, thanks!

I took out the mention of the unix socket from the README since it's not merged, so it's not very helpful to a user! We can add it to the readme when it's merged.

@ryanlovett I like your suggestions, however, if jupyter is running in a container, what is stopping a user from using a command line in the jupyterlab instance and just accessing the hidden services in the container that way? It seems like you again have issues where you need service-specific auth such as a token, or unix sockets like you suggested.

I see that unix sockets are part of jupyter-server-proxy now so this is kind of a moot point, but I'm curious if I'm misunderstanding how the container would have helped.

Thanks

@im-not-an-alien-i-swear-whos-ur-leader Usually jupyter-based containers are single user only, for example launched by a JupyterHub. In this case, only the one user can access the listening services in their container.

Having multiple users launch different jupyter servers within the same container that also run proxied services is not great from a security perspective, but people traditionally use containers to isolate processes.